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DETAILED ACTION 

1 . The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the phor art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary sl^ill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Claims 1-7 and 9-16 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Champagne (US 7,310,730 B1) in view of Putzolu (US 6,359,902 B1). 

Regarding claim 1 

Referring to claim 1 Champagne discloses a method in an intermediate node 
comprising a multicast/broadcast server and a streaming node for providing multicast 
for streaming transmission from a streaming server to users of a multicast group with 
the multicast/broadcast server providing multicast transmission and with the streaming 
node providing a streaming transmission based on an on-demand single -user 
signaling supporting the transmission of a streaming flow, the method comprising the 
steps of (Abstract: A method of communicating an encrypted data broadcast to a 
plurality of virtual private network receivers is disclosed. A first communication channel 
is established between a first one of the receivers and a network node. A private data 
stream is communicated to the first receiver on the first channel. A request is received 
from the first receiver to join a broadcast data stream that is directed to a plurality of 
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receivers by a broadcast server. A second encrypted communication channel is 
established between the first receiver and the network node for purposes of carrying the 
broadcast data stream. Decryption information, which the first receiver can use to 
decrypt information that is sent on the second channel, is sent to the first receiver 
through the first channel. The broadcast data stream is then communicated to the first 
receiver on the second channel. As a result, a particular receiver can receive an 
encrypted broadcast that is encrypted as part of a single session for a large plurality of 
other receivers, without impacting separate, private encrypted communications 
conducted by the particular receiver.) (Col. 6 lines 8-18 In block 306, a request from the 
first receiver to join a broadcast is received. The request may be an HTTP or RTSP 
request. For example, network node 202 receives a request from VPN client 21 4B to 
join a broadcast data stream originating at broadcast server 102. VPN client 21 4B may 
provide the request to the network node 202 by relaying a selection of a link or UR-L 
associated with broadcast server 102 that is made by an end user at personal computer 
1 16B. In this context, a "broadcast" or "broadcast event" refers to an event that ideally is 
multicasted, such as live streaming audio, video streaming, etc.) and (Fig. 2): 
establishing a bearer for a multicast transmission according to the requirements for 
streaming transmission (Col. 7 lines 1 1-22 In one particular approach, the broadcast 
event is unicast to each receiver using IPSec for encryption on the broadcast channel. 
Alternatively, the broadcasted event can be transmitted using generic routing 
encapsulation (GRE). In this approach, the broadcast server 102 communicates the 
broadcast using multicast to all elements of LAN 104 or network 108 that support 
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multicast, and uses unicast GRE tunnels for communication to clients through elements 
that do not support multicast. In this approach, for efficiency, the network element that 
originates the unicast streams could cache the broadcast stream.), establishing a multi- 
user streaming session on the bearer by translating the on - demand ( e.g. Video -On- 
Demand) single -user signaling received from the streaming server into multi-user push 
signaling ( Col. 7 lines 33-36 In this environment, the ISP could store the broadcast 
event as a confidential file in a cache local to a particular set of users. Such users then 
could retrieve, as Video-On-Demand, the broadcast event stored in the cache, which 
would be sent by unicast to the users.). Champagne did not discloses adapting the 
received streaming flow to the multicast transmission according to the needs of a 
multicast group or subgroup of a multicast group, replicating the received streaming 
transmission according to the number of the multicast subgroups. The general concept 
of adapting the received streaming flow to the multicast transmission according to the 
needs of a multicast group or subgroup of a multicast group, replicating the received 
streaming transmission according to the number of the multicast subgroups is well 
known in the art as taught by Putzolu. Putzolu discloses adapting the received 
streaming flow to the multicast transmission according to the needs of a 
multicast group or subgroup of a multicast group, replicating the received 
streaming transmission according to the number of the multicast subgroups.. 
(Col. 2 lines 19-35 At any given time, several multicast transmissions may be in 
progress, the different multicast transmissions being distinguished, for example, by the 
different destination IP addresses that identify each transmission. Each multicast 
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transmission may be described as a "multicast or multicast group channel." In order to 
allow users to select which multicast group to receive, a "Session Description Protocol" 
(SDP) message is sent over the network. The SDP message includes basic information 
about the multicast program, such as the title, time and location of various multicast 
being provided over the network. The end-user may then "tune in" to the desired 
multicast group using the information provided by the SDP message. The SDP 
transmissions are typically low-bandwidth uncompressed messages which can be 
accessed by most contemporary workstations operating in conjunction with even low- 
bandwidth network connections.) It would have been obvious to one of ordinary skill in 
the art at the time of the invention to modify Champagne to include adapting the 
received streaming flow to the multicast transmission according to the needs of a 
multicast group or subgroup of a multicast group, replicating the received streaming 
transmission according to the number of the multicast subgroups in order to provide any 
bandwidth or delay guarantees 

Regarding claims 15 and 16 

Claims 15 and 16 are similarly rejected using at least the same reasoning /citations 
provided for claim 1 since they recite the same limitations and are distinguished only by 
statutory category. 



Regarding claim 2 
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Referring to claim 2 Champagne and Putzolu discloses all the limitations of claim 2 
which is described above. Champagne also discloses further comprising the step of the 
streaming node communicating with the server adapts the streaming transmission and 
forwards the adapted streaming transmission to the multicast/ broadcast server (Col. 7 
lines 11 -22 In one particular approach, the broadcast event is unicast to each receiver 
using IPSec for encryption on the broadcast channel. Alternatively, the broadcasted 
event can be transmitted using generic routing encapsulation (GRE). In this approach, 
the broadcast server 102 communicates the broadcast using multicast to all elements of 
LAN 104 or network 108 that support multicast, and uses unicast GRE tunnels for 
communication to clients through elements that do not support multicast. In this 
approach, for efficiency, the network element that originates the unicast streams could 
cache the broadcast stream). Champagne did not discloses which replicates the 
received streaming transmission among subgroups of a multicast group. The general 
concept of replicates the received streaming transmission among subgroups of a 
multicast group is well known in the art as taught by Putzolu. Putzolu discloses 
replicates the received streaming transmission among subgroups of a multicast group. 
(Col. 2 lines 19-35 At any given time, several multicast transmissions may be in 
progress, the different multicast transmissions being distinguished, for example, by the 
different destination IP addresses that identify each transmission. Each multicast 
transmission may be described as a "multicast or multicast group channel." In order to 
allow users to select which multicast group to receive, a "Session Description Protocol" 
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(SDP) message is sent over tlie networl<. Tlie SDR message includes basic information 
about the multicast program, such as the title, time and location of various multicast 
being provided over the network. The end-user may then "tune in" to the desired 
multicast group using the information provided by the SDP message. The SDP 
transmissions are typically low-bandwidth uncompressed messages which can be 
accessed by most contemporary workstations operating in conjunction with even low- 
bandwidth network connections.) It would have been obvious to one of ordinary skill in 
the art at the time of the invention to modify Champagne to include replicates the 
received streaming transmission among subgroups of a multicast group in order to 
provide any bandwidth or delay guarantees. 

Regarding claim 3 

Referring to claim 3 Champagne and Putzolu discloses all the limitations of claim 3 
which is described above. Champagne also discloses the multicast/broadcast server i.e. 
server 102 communicating with the server i.e. server 103 (Fig.2). Champagne did not 
discloses replicates the received streaming transmission among the subgroups of a 
multicast group and forwards each replicated streaming transmission to the streaming 
node, which adapts each streaming transmission. The general concept of replicates the 
received streaming transmission among the subgroups of a multicast group and 
forwards each replicated streaming transmission to the streaming node, which adapts 
each streaming transmission is well known in the art as taught by Putzolu. Putzolu 
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discloses replicates the received streaming transmission among the subgroups of a 
multicast group and forwards each replicated streaming transmission to the streaming 
node, which adapts each streaming transmission. (Col. 2 lines 19-35 At any given time, 
several multicast transmissions may be in progress, the different multicast 
transmissions being distinguished, for example, by the different destination IP 
addresses that identify each transmission. Each multicast transmission may be 
described as a "multicast or multicast group channel." In order to allow users to select 
which multicast group to receive, a "Session Description Protocol" (SDP) message is 
sent over the network. The SDP message includes basic information about the multicast 
program, such as the title, time and location of various multicast being provided over the 
network. The end-user may then "tune in" to the desired multicast group using the 
information provided by the SDP message. The SDP transmissions are typically low- 
bandwidth uncompressed messages which can be accessed by most contemporary 
workstations operating in conjunction with even low-bandwidth network connections.). It 
would have been obvious to one of ordinary skill in the art at the time of the invention to 
modify Champagne to include replicates the received streaming transmission among 
the subgroups of a multicast group and forwards each replicated streaming 
transmission to the streaming node, which adapts each streaming transmission in order 
to provide any bandwidth or delay guarantees. 



Regarding claim 4 
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Referring to claim 4 Champagne and Putzolu discloses all the limitations of claim 4 
which is described above. Champagne also discloses wherein a decision unit is 
provided for deciding how the received streaming flow is to be directed in the 
intermediate node. (Col. 7 lines 11 -22 In one particular approach, the broadcast event is 
unicast to each receiver using IPSec for encryption on the broadcast channel. 
Alternatively, the broadcasted event can be transmitted using generic routing 
encapsulation (GRE). In this approach, the broadcast server 102 communicates the 
broadcast using multicast to all elements of LAN 104 or network 108 that support 
multicast, and uses unicast GRE tunnels for communication to clients through elements 
that do not support multicast. In this approach, for efficiency, the network element that 
originates the unicast streams could cache the broadcast stream). 

Regarding claim 5 

Referring to claim 5 Champagne and Putzolu discloses all the limitations of claim 5 
which is described above. Champagne also discloses wherein the streaming nodes 
have different capabilities and the multicast/broadcast server knows the different 
capabilities and addresses of the streaming nodes in order to select an appropriate 
streaming node for performing an appropriate adaptation of the streaming flow. (Col. 7 
lines 1 1-22 In one particular approach, the broadcast event is unicast to each receiver 
using IPSec for encryption on the broadcast channel. Alternatively, the broadcasted 
event can be transmitted using generic routing encapsulation (GRE). In this approach. 



Application/Control Number: 10/595,473 Page 10 

Art Unit: 2454 

the broadcast server 102 communicates the broadcast using multicast to all elements of 
LAN 104 or network 108 that support multicast, and uses unicast GRE tunnels for 
communication to clients through elements that do not support multicast. In this 
approach, for efficiency, the network element that originates the unicast streams could 
cache the broadcast stream.) and ( Col. 7 lines 58-62 In another approach, network 
node 202 may maintain a table of network address of known nodes that send 
broadcasts. Packets received at network node 202 are then examined and a lookup in 
the table is performed to determine if a broadcast node is sending the packets). 

Regarding claim 6 

Referring to claim 6 Champagne and Putzolu discloses all the limitations of claim 6 
which is described above. Champagne also discloses wherein in case a hierarchical 
coding (e.g. encryption) is used the streaming flows are differentiated in sense that a 
different number of layers is sent to different streaming nodes. (Col. 7 lines 47-57 In 
block 406, a broadcast event is detected. For example, network node 202 detects that 
broadcast server 102 has initiated a broadcast. Such detection may be performed using 
several approaches. For example, If the broadcast server 102 is multicasting the 
broadcast event, the network node may automatically detect that such an event requires 
a common encryption scheme for all VPN users. Alternatively, if the broadcast server 
does not use multicast, the VPN concentrator can detect that a broadcast event is 
occurring from request information in the protocol layers of event packets above the IP 
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layer.) and (Col. 8 lines 33-41The strength of encryption performed by common channel 
encryption engine 220D can vary. For example, the VPN concentrator can implement 
policy-based encryption based on the Layer 3 or Layer 4 attributes of the traffic 
generated by the broadcast server. As a specific example, network node 202 may 
examine the type of request received from the VPN client 21 4B and determine that for a 
phone conference meeting, 64-bit encryption is used, whereas for a company all-hands 
meeting, 128-bit encryption is used, etc.) 

Regarding claim 7 

Referring to claim 7 Champagne and Putzolu discloses all the limitations of claim 7 
which is described above. Champagne also discloses wherein the intermediate node 
administrates an address identifying the streaming flow arriving from the server. (Col. 7 
lines 47-57 In block 406, a broadcast event is detected. For example, network node 202 
detects that broadcast server 102 has initiated a broadcast. Such detection may be 
performed using several approaches. For example, if the broadcast server 102 is 
multicasting the broadcast event, the network node may automatically detect that such 
an event requires a common encryption scheme for all VPN users. Alternatively, if the 
broadcast server does not use multicast, the VPN concentrator can detect that a 
broadcast event is occurring from request information in the protocol layers of event 
packets above the IP layer.) and ( Col. 7 lines 58-62 In another approach, network node 
202 may maintain a table of network address of known nodes that send broadcasts. 
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Packets received at networl^ node 202 are tlien examined and a lookup in tlie table is 
performed to determine if a broadcast node is sending tlie packets). 

Regarding claim 9 

Referring to claim 9 Champagne and Putzolu discloses all the limitations of claim 9 
which is described above. Champagne did not discloses wherein the intermediate node 
receives a session description message informing about the transmission parameters 
required for the streaming session and said intermediate node changes the received 
parameters according to the needs of the subgroups that receive a dedicated replicated 
stream and sends the changed parameter to the group members by means of the multi- 
user push signaling message. The general concept of wherein the intermediate node 
receives a session description message informing about the transmission parameters 
required for the streaming session and said intermediate node changes the received 
parameters according to the needs of the subgroups that receive a dedicated replicated 
stream and sends the changed parameter to the group members by means of the multi- 
user push signaling message is well known in the art as taught by Putzolu. Putzolu 
discloses wherein the intermediate node receives a session description message 
informing about the transmission parameters required for the streaming session and 
said intermediate node changes the received parameters according to the needs of the 
subgroups that receive a dedicated replicated stream and sends the changed 
parameter to the group members by means of the multi-user push signaling message. 
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(Col. 2 lines 19-35 At any given time, several multicast transmissions may be in 
progress, the different multicast transmissions being distinguished, for example, by the 
different destination IP addresses that identify each transmission. Each multicast 
transmission may be described as a "multicast or multicast group channel." In order to 
allow users to select which multicast group to receive, a "Session Description Protocol" 
(SDP) message is sent over the network. The SDP message includes basic information 
about the multicast program, such as the title, time and location of various multicast 
being provided over the network. The end-user may then "tune in" to the desired 
multicast group using the information provided by the SDP message. The SDP 
transmissions are typically low-bandwidth uncompressed messages which can be 
accessed by most contemporary workstations operating in conjunction with even low- 
bandwidth network connections.) It would have been obvious to one of ordinary skill in 
the art at the time of the invention to modify Champagne to include wherein the 
intermediate node receives a session description message informing about the 
transmission parameters required for the streaming session and said intermediate node 
changes the received parameters according to the needs of the subgroups that receive 
a dedicated replicated stream and sends the changed parameter to the group members 
by means of the multi-user push signaling message in order to provide any bandwidth 
or delay guarantees. 



Regarding claim 10 
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Referring to claim 10 Champagne and Putzolu discloses all the limitations of claim 10 
which is described above. Champagne did not discloses wherein nodes higher up in the 
hierarchy are informed that the streaming flow is only to be forwarded to a single node 
lower in the hierarchy by means of a new message being distribute along the multicast 
delivery tree. The general concept of nodes higher up in the hierarchy are informed that 
the streaming flow is only to be forwarded to a single node lower in the hierarchy by 
means of a new message being distribute along the multicast delivery tree is well known 
in the art as taught by Putzolu. Putzolu discloses nodes higher up in the hierarchy are 
informed that the streaming flow is only to be forwarded to a single node lower in the 
hierarchy by means of a new message being distribute along the multicast delivery tree. 
(Col. 2 lines 19-35 At any given time, several multicast transmissions may be in 
progress, the different multicast transmissions being distinguished, for example, by the 
different destination IP addresses that identify each transmission. Each multicast 
transmission may be described as a "multicast or multicast group channel." In order to 
allow users to select which multicast group to receive, a "Session Description Protocol" 
(SDP) message is sent over the network. The SDP message includes basic information 
about the multicast program, such as the title, time and location of various multicast 
being provided over the network. The end-user may then "tune in" to the desired 
multicast group using the information provided by the SDP message. The SDP 
transmissions are typically low-bandwidth uncompressed messages which can be 
accessed by most contemporary workstations operating in conjunction with even low- 
bandwidth network connections.). It would have been obvious to one of ordinary skill in 
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the art at the time of the invention to modify Champagne to include nodes higher up in 
the hierarchy are informed that the streaming flow is only to be forwarded to a single 
node lower in the hierarchy by means of a new message being distribute along the 
multicast delivery tree in order to provide any bandwidth or delay guarantees 

Regarding claim 11 

Referring to claim 1 1 Champagne and Putzolu discloses all the limitations of claim 1 1 
which is described above. Champagne also discloses wherein the conversion between 
single-user on-demand and multi-user push signaling implies that certain messages are 
not propagated. (Col. 1 lines60-67 and Col 2 lines 1-4 Further, communicating 
broadcast media information using a VPN tunnel may significantly reduce the amount of 
bandwidth available to the VPN end user for other communications. Such end users 
may need to perform other kinds of communication such as email, telnet sessions or 
HTTP browsing using information that is specific to a particular end user. Because 
broadcast media typically have high bandwidth requirements, communicating such 
broadcasts on a large number of VPN sessions may exceed the maximum available 
encryption throughput of the VPN device. As a result, end users may be unable to 
communicate the user-specific information when a broadcast is in process). 
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Claims 12 ,13,14 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Champagne (US 7,310,730 B1) in view of Putzolu (US 6,359,902 B1) further in view of 
Voit (). 

Regarding claim 12 

Referring to claim 12 Champagne and Putzolu discloses all the limitations of claim 12 
which is described above. Champagne did not discloses wherein the replication of the 
streaming flow is based on an access network, in which users are located or/ and on the 
geographic area and /or on the Quality of Service a subgroup wishes for streaming 
sessions. The general concept of the replication of the streaming flow is based on an 
access network is well known in the art as taught by Voit. Voit discloses the replication 
of the streaming flow is based on an access network, (Col. 25 lines 45 -56 and Col 26 
lines 1-6 For a multicast service, such as the satellite-originated video broadcast 
service, the service provider sends one stream through the vertical services domain 
network 13 to the L3/4 ATM switch 19. The switch 19 will monitor every ATM virtual 
circuit going to the subscribers, looking for IGNP requests. A subscriber sends an IGNP 
request to join a selected multicast channel. When the L3/4 ATM switch 19 detects such 
a request, it identifies the requested channel and the requesting subscriber equipment 
and forwards a ^\o\n message to the vertical services domain. Subsequently, the switch 
19 replicates received packets for the requested broadcast channel, and the switch 
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drops the replicated packets into tine cells for each of the virtual circuits of all of the 
joined subscribers, including the newly added subscriber. When the subscriber later 
elects to end viewing of the multicast, the subscriber's equipment sends a 'leave' 
message, and the switch 19 stops adding the cells for the multicast to that subscriber's 
virtual circuit)., in which users are located or/ and on the geographic area and /or on the 
Quality of Service a subgroup wishes for streaming sessions (Col. 35 lines 33-51 FIG. 
12 provides a flowchart that summarizes the steps taken by the CPE in forwarding 
Ethernet frames to the ADN. In step 1202, an Ethernet frame is received at one of the 
interface ports. The Ethernet frame encapsulates datagrams. Information related to an 
upper-layer protocol is extracted, in step 1204, from the received frame. Examples of 
such information include the destination IP address encapsulated within the Ethernet 
frame. A set of rules (e.g., a routing table) is consulted to determine, in step 1206, what 
ethertype encapsulation needs to be used based on the extracted upper-layer 
information. Once the ethertype encapsulation method is identified, the datagram is re- 
encapsulated, in step 1208, using the identified ethertype encapsulation method. Once 
encapsulated, the frame, in step 1210, is forwarded upstream over the ADN. In 
performing the forwarding step (step 1210) the CPE can also consult security access 
control lists to identify permissible connections and sessions and block Ethernet frames 
when appropriate. Similarly, the CPE can also perform the forwarding step in a manner 
to ensure conformance with any QoS parameters associated with the upstream 
bandwidth.). It would have been obvious of one of ordinary skill in the art at the time of 
the invention to modify Champagne to include wherein the replication of the streaming 
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flow is based on an access network, in which users are located or/ and on the 
geographic area and /or on the Quality of Service a subgroup wishes for streaming 
sessions in order to provide any bandwidth or delay guarantees. 

Regarding claim 13 

Referring to claim 13 Champagne, Putzolu and Volt discloses all the limitations of claim 
3 which is described above. Champagne also discloses wherein the intermediate node 
requests the actual characteristics of the area in order to adapt the streaming flow 
accordingly. (Col. 7 lines 1 1-22 In one particular approach, the broadcast event Is 
unicast to each receiver using IPSec for encryption on the broadcast channel. 
Alternatively, the broadcasted event can be transmitted using generic routing 
encapsulation (GRE). In this approach, the broadcast server 102 communicates the 
broadcast using multicast to all elements of LAN 104 or network 108 that support 
multicast, and uses unicast GRE tunnels for communication to clients through elements 
that do not support multicast. In this approach, for efficiency, the network element that 
originates the unicast streams could cache the broadcast stream). 



Regarding claim 14 
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Referring to claim 14 Champagne and Putzolu discloses all the limitations of claim 3 
which is described above. Champagne discloses wherein the intermediate node 
provides additional information to the charging /billing server in order to guarantee an 
accurate charging and /or multi-user streaming related charging. (Col.26 lines 35-52 
Although IP-based, the services from the vertical services domain 13 may follow any 
other desirable business model. For example, a multicast service provider may contract 
with the carrier to provide multicast audio (radio-like) and/or video (TV-like) services via 
the vertical services domain. The multicast service provider, not the subscribers, would 
pay the carrier. The multicast service provider may offer any or all of the multicast 
programming to customers on some type pay-per-view basis but would likely offer most 
of the programming service for free or bundled in as part of some nominal monthly 
subscription charge . The multicast service provider instead would charge advertisers in 
a manner analogous to current broadcast business practices. Advertising distributed 
with the IP multicasting, however, can be carefully targeted at end-customers having 
demographic profiles meeting specific criteria specified by individual advertisers, which 
allows the multicast service provider to charge premium advertising rates. ) and (Col.26 
lines 16-34 In an enhanced service offering, the broadcast provider could offer a 
convenient navigation Interface from a web server. The server could be on the vertical 
services network, but preferably is on the wide area Internet 1 1 . With a PPPoE session 
active, the user can surf to the provider's server and view information about available 
programming. The user might select a current broadcast program by 'clicking' on a URL 
link in the provider's web-based information. Although provided through the wide area 
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Internet 11 , the URL would actually contain the private IP address for the desired 
broadcast program available from the vertical services network 13. Selection of such a 
URL therefore would generate a message to the appropriate server on the vertical 
services network 1 1 to initiate the above discussed procedure to allow the user to ^\o\n 
the selected broadcast. A similar methodology might also enable a provider to offer 
menu, selection and order/billing services from the Internet 1 1 , to provide pay-per-view 
or video on-demand type services from the vertical services domain network 13). It 
would have been obvious to one of ordinary skill in the art at the time of the invention to 
modify Champagne to include the intermediate node provides additional information to 
the charging /billing server in order to guarantee an accurate charging and /or multi-user 
streaming related charging in order to provide any bandwidth or delay guarantees. 

Claim 8 is rejected under 35 U.S.C. 103(a) as being unpatentable over Champagne (US 
7,31 0,730 B1 ) in view of Putzolu (US 6,359,902 B1 ) further in view of Cannon (US 
6,014,706). 

Regarding claim 8 

Referring to claim 8 Champagne and Volt discloses all the limitations of claim 8 which is 
described above. Champagne did not discloses wherein the intermediate node 
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receives a session description message informing about tlie transmission parameters 
required for the streaming session and forwards tine received parameters to the group 
members by means of the multi-user push signaling message. The general concept of 
wherein the intermediate node receives a session description message informing about 
the transmission parameters required for the streaming session and forwards the 
received parameters to the group members by means of the multi-user push signaling 
message is well known in the art as taught by Cannon. Cannon discloses wherein the 
intermediate node receives a session description message informing about the 
transmission parameters required for the streaming session and forwards the received 
parameters to the group members by means of the multi-user push signaling message 
In a particularly advantageous embodiment, the fast forward stream is employed for fast 
forwarding. The steps taken by the server to ascertain the first data packet of the fast 
forward stream to send when transitioning from the real-time play mode (or other modes 
except live play) to the fast forward mode are depicted in FIG. 8. In step 802, the server 
seeks back in the fast forward stream from the video frame whose time corresponds or 
most closely corresponds to the time parameter sent from the client to the server in step 
502 for the first frame to be sent. Alternatively, the server may seek forward in the fast 
forward stream from the video frame whose time corresponds or most closely 
corresponds to the time parameter sent from the client to the server in step 502 for the 
first frame to be sent. The fast forward stream, like the play stream, are stored in the 
server as the recording session progresses as video files. It would have been obvious 
to one of ordinary skill in the art at the time of the invention to modify Champagne to 
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include wherein the intermediate node receives a session description message 
informing about the transmission parameters required for the streaming session and 
forwards the received parameters to the group members by means of the multi-user 
push signaling message in order to provide any bandwidth or delay guarantees. 

Response to Arguments 
Applicant's arguments filed on 10/06/2008 have been fully considered but they are 
deemed moot in view of the new grounds of rejections. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ashley d. Turner whose telephone number is 571-270- 
1603. The examiner can normally be reached on Monday thru Friday 7:30a.m. - 
5:00p.m.. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Nathan Flynn can be reached at 571-272-1915. The fax phone number for 
the organization where this application or proceeding is assigned is 571-270-2603. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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